PM 叫你去改一个 Bug，后来……
（点击上方公众号，可快速关注）
编译：伯乐在线/Erucy
你曾经碰到过现在这种情况：
你的代码非常优雅。
你代码中的抽象刚刚好，不多不少。
你的模块都各自独立。
所有的测试结果都是绿色的。代码测试覆盖率报告花了整整一分钟才打开，上面显示着 97%……
生活很美好。
然后事情就这么发生了。
一个 PM（产品经理）跑进来，跟你说上周你发布的那个更新里面有个 bug。不论什么时候，只要用户在购物车里添加了一件商品，购物车中的计数过个好几秒才会更新。本来应该立即更新的。
PM 跟你说用户的抱怨如潮水般用来，他问你：你能看一眼么？
当然你能看一眼，毕竟这是你做的东西。很可能是其他什么人犯了错。不过你会修复这个问题的。你就是这么正直的员工。
你在 Git 上把最新的发布版本同步下来，然后开始研究变更日志。在上一个发布版本中，你把 HTTP request 库更新到了最新版。那次审核过了好长的时间。你还能记得这次修改确切的提交所在，那天的天气不错。
你切换到那次提交，然后模拟了一下更新购物车的请求。不错 ，你已经充分考虑到了代码的独立性，可以很容易地在测试环境和生产环境中进行测试，只需要切换一个构建标记就够了。
你找到了那个罪魁祸首。看起来你更新的那个 HTTP 库有个回归（regression）。对于特定类型的请求，它花了太长的时间来解析传入的 JSON 负载。你的应用只能在请求负载解析完成之后才能更新那个计数器。在架构上还没有处理最终一致性的问题，要加上这种设计的话，本身就足够当成一个项目来做了。所以你没法在本地先更新计数器随后再同步到服务器上。
你知道这是别人犯的错。唉，这就是生活。
你把事情的原因告诉了 PM。他拍了拍你的背，知道这不怪你。你能把这个问题修复么？
当然。
你已经考虑好你的解决办法。
你不能把变更都回滚。有一大堆新的代码和 bug 的修复都依赖于这个新版的库，要是你把所有东西都回滚的话，这些就都白干了。
只是把这个库 fork 下来然后维护一个你自己的版本看上去也不太可行。之前这个项目的维护者有一个超级完备的测试架构，会在上千台设备上测试你修复的代码。而你只有三台设备，其中两个的操作系统版本都老掉牙了。最好还是需要他们的反馈，毕竟这是他们维护的库，他们对其内部结构很了解，而你不了解。
所以你打算这么干：
Fork 这个库
实现代码修复
向原始的 repo 中发一个 pull request
你和维护者可能需要来回几次沟通
最终说服他们相信你的方法才是最好的
代码合并
等着这个库发布一个新的补丁
在你的代码中更新这个库
发布产品的新版本
很简单嘛。
“好极了，”PM 说，“你觉得需要花多长时间？”
你知道这个答案。人们都说程序员不会估算时间，你可不是那种程序员。（《为什么软件开发周期通常是预期的两三倍？》）
“两周，”你眼都不眨地说，“取决于这个 PR 多久才会被接受，还有维护的人多快能发布一个新版本。”
PM 的脸色立刻就变绿了。“两周？两周？！”他重复着同样的话，好像这样能改变一样。不过他还是保持了冷静。PM 知道怎么处理负面的情绪，没什么可担心的。
“我们的用户正在流失！他们什么都不会买了，因为他们没法看到自己购物车里面的更新！我们是个电商公司！这是不可接受的！”
你看着他经历着悲伤的五个阶段（译注：否认、愤怒、讨价还价、绝望、接受）。你等着最后接受的那个过程什么时候会发生。不过并没有。他看起来停在了讨价还价的阶段。
“好吧，”你说着，深陷在你的转椅里，“让我想想。”
你会迁就他一下下，然后他可能就会离开了。你还有很多其他事情要做，你知道的。
你开始翻看源代码。这是你的特长，你的手指敲击着 IDE 的快捷键，就好像海神波塞冬驾驭着大海的波涛。
啊哈！你找到它了！有个文档中没提到的方法，可以在 JSON 解析的代码中插入一个钩子，然后用你自己的实现来替换它！
不过等等。这看起来太丑陋了。这可是个非公开的 API，说不定把它暴露出来是个意外呢。你可不想依赖这种东西，万一他们在下一个版本里把它移除掉了怎么办？那样你就得把这套东西整个都重写一遍了。谁想这么干啊？不过这确实比自己维护一个没测试过的分支要快一些。不过还是太丑陋了。
不要。
你可不想因为商务决策而误导你，毁了你纯净的神殿。你是神圣的守护者，对抗着那些愚昧的事物。这就是为什么他们会付你那么多钱的原因。你的责任就是拒绝这种要求。
你冲进 PM 的屋子。“答案是不要。没有什么优雅的方法来解决它，我不相信丑陋的旁门左道。抱歉。”
他的反应和你预料中的一样。
“你告诉我有个方法可以做到，不过你不想这么做就因为它不够优雅？我们的用户正冲我们叫嚣着，威胁我们要改用我们竞争对手地产品，而你就不愿意修复这个问题，就因为它不够优雅？“
你失败了。
这人懂什么软件工程？你只用代码就凭空创建了这个奇妙的世界。高度可扩展的系统，可以抵抗住来自前苏联集团中所有黑客发向你的 DDoS 攻击。你是个艺术家，而芯片就是你的画布。你已经无数次地阅读了《代码整洁之道》，你对它的了解甚至超过了你对自己 GitHub 密码的印象。
“没错！”你喊道，“我不会用这种垃圾来玷污我们的代码库！我花了好几个月才构建出这些东西！产品里的每一行代码都是我的心血！它们能够正常运行的唯一原因不是你，和你没关系！是像我这样的人们维持着软件的运行，是像我这样的人们，不得不在你和你的那些‘商业功能’完成之后去清理那些乱七八糟的东西！”
你冲出了那儿。你需要喝点什么。这样的人简直就是业界的祸根。他们觉得自己那些花哨的 MBA 证书能让他们知道该如何创造出伟大的软件，而我们这些开发者却不知为什么忽略了这种方法。
你昂首阔步地走进休息区，那是你每天享用那些美食家们推荐的午餐的地方。还有咖啡，不限量的、美味的、滋润着你的灵魂的咖啡。你值得这种享受，因为你是个知识工作者。
你冲了一杯 Java 咖啡，想找个地方坐下。
然后你看到了他。
你的公司中最资深的程序员。
这家伙是个彻头彻尾的核心人员，是那种“我在上厕所的工夫就能写出一个编译器”的程序员。在黑客出现之前他就已经是名黑客了。你想要成为这样的人。他就像是指环王里面的甘道夫。这里所有人在所有时候都尊敬和畏惧着他。不过他很和蔼，总是会帮助那些孩子们。他应该愿意听听你和 PM 之间发生的事情。毕竟，他是你这一伙的。
于是你坐到他旁边。他正享受着咖啡，正在看着什么 Haskell 中抽象的数据类型之类的东西。
没错，就得和这样的人聊聊。
你把自己的壮举告诉了他。他耐心地听着，偶尔点点头，问了些问题。他的肢体语言是向后靠着。从他的眼神中你能看得出来，他以前也经历过这种事儿。
你终于说完了。
好累。
你感觉肩上的分量轻了一些。
他看上去陷入了沉思，好像正在谨慎地选择着词汇。
你等着他会大笑着宣布“干的好，孩子！”，然后你们会一起再冲杯咖啡。他会给你讲一个他所经历过的类似的故事，在那一天，他如何斥责一个愚蠢的 PM。
你曾经梦想过这一天。你们会用咖啡碰杯，就像那些在战场上取胜的战士那样。至少，在电影里他们是那么干的。当然，他们通常用的是啤酒，而不是咖啡。
在感情上，你是这么希望的。
你等待着……
继续等待着……
他直直地看向你的双眼，穿透了你的灵魂。那些和电脑一起奋斗过的岁月让他的目光变得如此难以忍受，不过他使用了什么魔法，让你无法移开你的眼睛。
他只说了一件事。
“我们的工作并不是喝喝咖啡敲敲代码。我们的工作是编写能够正常运行的软件。”
然后他就走开了。
你呆住了一分钟。在你肚子里有种什么感觉，一种空荡荡的、恶心的感觉。你开始意识到这种感觉，叫做羞愧。
你让那些你最亏欠的人失望了，那就是你的用户。
于是你回到自己的座位上，迅速搞定了那个“旁门左道”，然后发布了一个新的版本。
你向 PM 道了歉，自己有点失控了。他说没事。最后只要没事就好。
你还是 fork 了这个库，实现了一个正确的修复方式，然后提交了一个 PR。当这个库以正确的解决方法发布新版本的时候，你总是可以重构自己的代码的。
看完本文有收获？请转发分享给更多人
关注「程序员的那些事」，编程更有趣